Форма входа
0/0
Настольная книга тимлида разработки ПО - Виктор Большаков
- Дата:29.07.2024
- Категория: Компьютеры и Интернет / Программирование
- Название: Настольная книга тимлида разработки ПО
- Автор: Виктор Большаков
- Просмотров:3
- Комментариев:0
Уважаемые читатели!
Тут можно читать бесплатно Настольная книга тимлида разработки ПО - Виктор Большаков. Жанр: Программирование. Так же Вы можете читать полную версию (весь текст) онлайн книги без регистрации и SMS на сайте Knigi-online.info (книги онлайн) или прочесть краткое содержание, описание, предисловие (аннотацию) от автора и ознакомиться с отзывами (комментариями) о произведении.
Описание онлайн-книги Настольная книга тимлида разработки ПО - Виктор Большаков:
Книга родилась из курса внутреннего обучения роли Тимлид в DatsTeam. Тем не менее её ценность для всего сообщества тимлидов заключается в обобщении необходимых компетенций. Этот набор компетенций формирует общий стандарт в отрасли разработки ПО.
Программирование
Аудиокнига "Настольная книга тимлида разработки ПО" от Виктора Большакова
📚 "Настольная книга тимлида разработки ПО" - это увлекательное путешествие в мир управления разработкой программного обеспечения. Вас ждет множество полезных советов, инсайтов и стратегий, которые помогут вам стать успешным лидером в IT-индустрии.
Главный герой книги - тимлид, который сталкивается с различными вызовами и проблемами в процессе работы с командой разработчиков. Он учится принимать решения, мотивировать коллег и эффективно управлять проектами, чтобы достичь поставленных целей.
Автор книги, Виктор Большаков, является опытным специалистом в области разработки ПО и управления проектами. Он делится своими знаниями и опытом, помогая читателям развить лидерские качества и стать успешными профессионалами в IT-сфере.
На сайте knigi-online.info вы можете бесплатно и без регистрации слушать аудиокниги онлайн на русском языке. Здесь собраны лучшие бестселлеры различных жанров, включая книги по программированию.
Не упустите возможность улучшить свои навыки управления проектами и стать успешным лидером в области разработки ПО с помощью аудиокниги "Настольная книга тимлида разработки ПО" от Виктора Большакова!
Погрузитесь в увлекательный мир IT-индустрии и станьте лучшей версией себя уже сегодня!
Программирование
Читем онлайн Настольная книга тимлида разработки ПО - Виктор Большаков
Шрифт:
-
+
Интервал:
-
+
Закладка:
Сделать
чем они не согласны. Вероятно, вы не вовлекли сотрудников в этап проектирования процесса, что породило их несогласие.
— если доводы разумные, можно включить их в следующую итерацию изменения процесса. Например, исправить его через некоторое время — сообщите об этом сотрудникам и попросите работать пока в текущей версии процесса.
— если их доводы не разумные, объясните почему.
— если это личная неприязнь к вам и саботаж просто способ выражения этой неприязни, то необходимо перечитать главу Конфликтология и решать этот вопрос указанным там способом.
— Сотрудники не знают, как правильно следовать новому процессу.
— вы могли совершить ошибку, не описав нужные вещи в процессе, или ваши сотрудники невнимательно изучили сделанный материал. Так или иначе, это больше обычная ситуация нежели саботаж.
— Новый процесс имеет критические ошибки и нуждается в пересмотре
Контролируйте новый процесс первое время, как писал пластический хирург Максвелл Мальц: «Человеку нужен 21 день, чтобы привыкнуть к изменениям своего тела». Этот срок в «21 день» применяют и для других случаев, где людям необходимо привыкнуть к чему-то новому. Если это редкий процесс, то отсчитывайте 7–9 итераций этого процесса до смягчения вашего контроля.
Эволюция процесса разработки
Конструируя свой процесс, необходимо отталкиваться от основных параметров:
— Долгосрочное или краткосрочное сотрудничество у вас с заказчиком
— Насколько жестко ограничены срок и требования к продукту
Процесс разработки будет меняться со временем и на то есть определенные причины:
— Меняются люди в команде
— Меняется количество людей в команде
— Меняются требования к качеству продукта
— Появляются риски, которые сыграли
— Подходит плановая оптимизация процесса
— Появляются жалобы и предложения
Вам нужно будет достаточно часто менять и адаптировать процесс разработки к изменяющимся условиям. Есть лучшая практика для оптимизации процессов — Цикл Деминга.
Цикл Деминга (PDCA) закладывает в управление процессом постоянное улучшение качества.
Эдвард Деминг заложил два варианта для цикла управленческих действий постоянного улучшения качества: PDCA (планируй/Plan — делай/Do — проверяй/Check — корректируй/Act) и PDS А (планируй/Plan — делай/Do — изучай/Study — корректируй/Act):
— Планирование: установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов.
— Выполнение: выполнение запланированных работ.
— Проверка: сбор информации и контроль результата на основе ключевых показателей эффективности (KPI). Они получаются в ходе выполнения процесса, выявления и анализа отклонений и установления причин отклонений.
— Воздействие: (управление, корректировка) принятие мер по устранению причин отклонений от запланированного результата, а также изменений в планировании и распределении ресурсов.
Цикл Деминга ни что иное как здравый смысл, примененный к любому происходящему во времени процессу, которому необходимо постоянное улучшение. Процесс непрерывного совершенствования поддерживается многими методологиями. Например, в Scrum есть встречи Sprint Retrospective, а в ITIL есть Continual Service Improvement. Так или иначе все приходят к реестру, процессу выявления улучшений и плановой работе с ними.
Есть несколько способов поиска улучшений:
— Анализ потерь на всех этапах решения задач. Такой анализ может происходить на встречах Sprint Retrospective.
— Анализировать основные метрики процессов и предпринимать действия по их постоянному улучшению. Важно обеспечить непрерывность их роста, а не большую величину роста.
Лучшие практики разработки и особенности их применения
Существует множество хороших практик разработки. Важно выбрать из них те, что подходят к конкретному случаю.
Kanban (применяем при высокой неопределенности в приоритетах/размерности задач/ бэклоге)
— Доска для наглядности не сможет вместить большого количества тикетов
— Работать с подзадачами на доске неудобно
— Приоритеты можно менять на лету
— Нет издержек на оценку задач
— Сложно попасть в сроки по плановым задачам
Scrum (применяем если можем планировать на 3+ итерации, нет фиксированного бюджета или требования могут измениться)
— не работает с совмещенными ресурсами (сотрудники, выполняющие задачи разных команд)
— работает в условиях краткосрочного планирования
— подразумевает отсутствие четкого конечного образа продукта
— кросс-функциональные команды подразумевают способность подменить одного специалиста другим (больше подходит для Fullstack разработчиков), и производство менее сложных продуктов
— подразумевает само-организованные команды, что требует найма команды с определенными soft skills
— ввиду избегания конечного образа продукта страдает область архитектурного планирования
ServiceDesk (применяем, если необходимо обеспечить единый временной норматив выполнения заявок)
— отсутствует планирование
— задачи могут быть большими, но они должны укладываться в временные рамки SLA
— приоритет выставляет поддержка, а не бизнес.
Существует еще множество различных лучших практик, подробно рассмотреть их в рамках данной книги невозможно. Для себя вы можете почитать про RUP, ITIL. RAD, Lean SD, Six Sigma, MSF. XP. PMBOK. Prince2. Но стоит четко отделять практики WoW (way of working) вашей команды, от практик корпоративного уровня SAFe, LeSS, Disciplined Agile.
Менеджер процесса разработки
Менеджер контролирует выполнение процесса, спроектированного Владельцем процесса.
«Управляешь только тем, что можешь измерить»
американский ученый и публицист Питер Друкер
Менеджер на ежедневной основе выполняет аналогичный цикл PDCA, собирая информацию о результативности, выявляя проблемы процесса и устраняя их.
Как собирать информацию?
Для каждого процесса определена измеримая цель. Более того, измерить можно не только поток работы, но и качество результатов на каждом шаге. Обычно самый простой способ — контролировать итоговый результат, быстро привлекая менеджера к этапам более глубокого контроля. Без этого каждый раз будет затрачиваться много времени на выяснение причин плохих метрик итогового результата.
Конечно, кроме всего прочего, необходимо быстро анализировать информацию — собираемые метрики должны выводится на графики.
Также оперативную информацию можно получать от исполнителей на ежедневных встречах (или других отчетных собраниях).
На основании анализа репозитория и сервиса проведения ревью можно собрать множество метрик, например:
— выгорания — коммиты, комменты в нерабочее время
— лени — мало кода, мало коммитов, мало ревью, мало задач, мало активных дней
— фокуса на задачу — простой после ревью, простой после тестирования и ожидание релиза
— качество — churn, возврат из тестирования, фиксы на проде
— bus-фактор — области изменения кода
— качество постановки задач — частота изменений описаний, churn
— технический долг — высокий complexity, низкий уровень рефакторинга legacy
Как выявлять проблемы?
Выявление проблем может быть построено на данных анализа и полученных путем изучения трендов, и пороговых значений статистических данных. На практике у вас должен быть дашборд с графиками и информацией, достаточной для понимания работы процессов и людей.
На основании выявленного отклонения необходимо исследовать природу этого события. Дедуктивным методом вы докапываетесь до исходной причины, также вы можете применить метод «5 почему». По итогу анализа вы придете к одному типу первопричины проблемы: внешние факторы, процесс, сотрудники. Копайте так глубоко, насколько это будет возможно/необходимо, ведь не докопавшись
На этой странице вы можете бесплатно читать книгу Настольная книга тимлида разработки ПО - Виктор Большаков бесплатно.
Похожие на Настольная книга тимлида разработки ПО - Виктор Большаков книги
- Настольная книга по домоводству. 1000 практических советов на все случаи жизни - С. Потапкин - Прочее домоводство
- Мама, я тимлид! Практические советы по руководству IT-командой - Марина Перескокова - Программирование
- Формирование технологии разработки и принятия предпринимательских решений - Д. Кенина - Управление, подбор персонала
- Исправление прошлого и исцеление будущего с помощью практики восстановления души - Альберто Виллолдо - Эзотерика
- Личное мнение - Павел Бессонов - Поэзия
